在當今快速變化的工作環境中,自我反思與團體反思已成為提升個人表現與團隊產出的重要方式。因此今天想來聊聊過去一年的我如何在Product Development team的工程師團隊裡建立良好的feedback文化。
Day | 規劃主題 |
---|---|
Day21 | Job transfer轉折篇: 人資部門專案經理 |
Day22 | 成長篇:在AI時代持續學習 |
Day23 | 成長篇:建立系統回饋機制 - 自我反思與團隊反思 |
Day24 | 成長篇:建立社群個人品牌 |
Day25 | 成長篇:職涯與職場支持系統 |
在團隊中要建立系統回饋機制的第一點,建立真實誠懇的開放文化。
人不會被AI取代的地方就是能真實表達感受力
。在這一年來,我會定期透過1 on 1會議去取得個人回饋。這是讓我能專注傾聽團隊成員的想法難能可貴的機會。我能夠提出自己平時的觀察,透過真誠的互動並給予適當的回饋和激勵。
這樣對話的過程不僅能促進成員之間的信任,也讓我發現我自己的優勢是特別擅長根據成員的優勢、強項和特質來安排適當的任務。當成員分享在任務中卡關又解完所獲得的經驗教訓(lesson learned)如何幫助他們成長,這樣的對話過程總是讓人感動不已。
最近距離上次的1對1會議已經過去半年多,團隊的組成也發生了相當大的變化。資深成員的離開和眾多新成員的加入,整體團隊的結構從前端和後端的比例由2:3變成了4:4。這樣的變化帶來了成長的機會也面臨著挑戰。
目前超過一半的成員加入團隊不到半年,如何讓他們熟悉codebase和產業領域知識(domain know-how),舊系統知識的傳承與分享,成為了我們需要面對的重大挑戰。我們必須確保知識不會因為集中在少數人的腦袋裡而導致不必要的風險。
另外,團隊中跨文化的磨合也是一個不容忽視的挑戰。隨著部分外國同事的加入,我們的工作模式從全部台灣同事在公司上班(on-site)轉變為混合模式(hybrid)。每天的日常會議(daily scrum)中,大家開始習慣用全英文進行交流。在英文的回顧會(retro)中,成員們也越來越能夠敞開心扉,分享自己的觀點。
目前我們的會議都是在線上進行,工程師們幾乎不開愛鏡頭,僅透過聲音辨識彼此。我認為最大的挑戰是在這樣的背景下創造一個信任與開放的團隊討論氛圍
,讓大家願意坦誠地分享工作上的困難,而不是讓會議流於形式。
首先,團隊對問題的共識是關鍵,我會根據即將發生的重要議題引導討論(例如:識別某項未解決bug,會為未來帶來怎麼樣的風險),進行優先順序的討論。
當大家都同意某個問題的重要性後,下一個衝刺(sprint)中就會實際投入時間和資源來討論這些項目。
每次sprint的結束我會持續關注是否有改善,確保每個衝刺的體驗都比上一次更好,每一次的srcum meeting都針對這樣的PDCA(Plan-Do-Check-Ack)循環越來越優化。
線上協作軟體的使用:在會議開始前,花約10分鐘的時間讓每位成員將最想表達的內容先記錄下來,並分享給所有人。這樣的做法不僅能讓習慣使用中文的同事先用中文寫下觀點並透過翻譯先順稿,也能在發言時增強他們的自信。若有成員在表達時遇到困難,我或其他同事會協助翻譯,確保每個人的聲音都能被聽見。
輪流發言的機會:在會議中每位成員都有3-5分鐘的發言時間,無論多或少都沒關係。如果某位性格較內向的成員提到值得討論的事項,我會主動引導他們多發言,或者邀請他們補充相關資料。這樣的方式不僅促進了討論,也讓新進同仁意識到,只要勇於表達他們所關心的問題,一定有人願意傾聽與重視。
隨著我們的信任度逐漸增加,主導的資深成員通常會引導深入的討論,而新進成員也開始意識到,只要願意表達自己的觀點,就會有人重視他們的聲音。無論成員來自哪個背景 / 國家,這樣的氛圍讓每個人都能成為推動團隊改變的重要力量。
自我反思與團體反思的過程不僅促進團隊成員之間的信任與合作,也能提升整體工作效率和產出。(畢竟每次老闆都會說:「產品開發團隊(工程師人力成本)最貴」。產出效率差是會被定到牆上的呀)
透過持續的反思與改進,我們不僅能夠越來越能理解彼此的觀點,也能夠在面對挑戰時找到最適合目前團隊的解法。
我相信我們的產品開發團隊會在未來的日子裡,迎來更多的使用者成長,做出能成功影響這個世界的產品~~